Individualized data sharing

ABSTRACT

A method may include: maintaining one or more attributes of a first user; maintaining a risk profile scheme configured by the first user, the risk profile scheme comprising a passive permission table indicating whether a second user has permission to the one or more attributes; allowing the first user to grant dynamic permissions to the second user to access the one or more attributes in accordance with the risk profile scheme; allowing the first user to perform content blobulation of the one or more attributes; and allowing the first user to perform content reblobulation of the one or more attributes in accordance with the risk profile scheme.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is continuation application of U.S. Ser. No.12/793,597, filed Jun. 3, 2010, entitled “Individualized Data Sharing,”,which is a continuation-in-part (CIP) of U.S. Pat. No. 8,108,533, issuedJan. 31, 2012, which is a continuation of U.S. Pat. No. 7,698,445,issued Apr. 13, 2010, which claims priority to U.S. Provisional PatentApplication No. 61/183,942, filed Jun. 3, 2009, all of which areincorporated by reference.

BACKGROUND

Access to data stores or computer-readable mediums is often governed orregulated by permissions. Permissions expressly or impliedly indicatewhich users may access a data store, and to what extent. Permissionsoften impliedly or indirectly indicate a user's permitted access byreferring to a permissions group of which the user is a member. Apermissions group typically includes a set of member data store userswith a common degree or level of permitted access; an association with adata store, set of data stores, or part of a data store; and adefinition of the common degree or level of permitted access.Permissions often indicate the degree or level of access to anassociated data store, set of data stores, or part of a data store witha set of modifiable variables, a set of preset parameters, a referenceto a set of modifiable variables, or a reference to a set of presetparameters specifying whether the data entries in the associated storagemay be viewed, modified, deleted, or created.

The existing systems address permissions and attributes stored on aserver, and accessible to a querying client when the server is onlineand permissions are satisfied. However, some or all permissions andattributes may be stored on a client's local storage medium, such ashard drive in a workstation, or memory in a cell-phone or PDA, wherethey are inaccessible when the client is unavailable.

The present computer system and methods may address these and otherneeds.

SUMMARY

A technique for providing attributes to a client with permission toaccess those attributes involves receiving a request, and querying anagent for the attributes. A system built according to the technique mayinclude a first client capable of requesting one or more attributesassociated with an unavailable second client; one or more client agentsstoring at least one of the one or more attributes of the second client;a server for receiving the first client's request, the server having apermissions datastore for storing a data entry specifyingattribute-sharing permissions between the first client and the secondunavailable client; wherein, in operation, the server forwards therequest to the one or more agent clients for the one or more attributesassociated with the second client.

A method according to the technique may include receiving a query from afirst client for one or more attributes associated with a second client;if the first client has permission to access at least one of the one ormore attributes associated with the second client, querying an agentclient storing data associated with the at least one of the one or moreattributes; replying with the at least one of the one or more attributesfrom the agent client.

A content owner may also be able to grant dynamic permissions to“content blobs.” This enables a content owner to grant permissions onthe fly.

This summary is provided by way of example, but not limitation. It isintended to give a brief overview of some aspects and embodiments of theinvention, but further examples and embodiments are described below.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a conceptual view of a data sharing system.

FIG. 2 depicts a system that provides permissions for query accesscontrol based on attributes.

FIG. 3 depicts an embodiment in which there are several client agents incontact with a server.

FIG. 4 depicts a conceptual view of a system for individualized datasharing.

FIG. 5 depicts flowchart of a method for utilizing dynamic permissionsfor content.

FIG. 6 depicts a flowchart of an example of a method for self-managementof personal information sharing.

FIG. 7 depicts a system on which a framework for individualized datasharing can be implemented.

FIG. 8 depicts a conceptual drawing of a federated system.

DETAILED DESCRIPTION

A computer system and methods are described for allowing a first client(e.g., a querying client) to obtain one or more attributes, i.e.,personal, privileged, or otherwise sensitive information, associatedwith a second client (e.g., a queried client) via client agents, wherethe clients are connected at some point to a server, which grantspermissions as specified, at least in part, by the second (queried)client.

The computer system and methods are described below, with reference tothe accompanying figures (FIGS.), which are intended to illustrate,rather than limit, the system and methods. The terms “clients” and“subscribers” are used interchangeably, unless noted. A “first” clientgenerally denotes a querying client, e.g., a system subscriberrequesting attributes from a queried subscriber. A “second” clientgenerally denotes a queried client, from which an attribute is sought.

I. Server System and Clients/Subscribers

FIG. 1 depicts a conceptual view of an exemplary system in which thepresent system and methods may be applied. The system 100 includes afederated control server 102, a network 104, clients 106-1, 106-2, 106-N(referred to collectively as clients 106), mobile devices 108-1, 108-2,108-N (referred to collectively as mobile devices 108), and a clientserver 110. Communications between the server 102 and the clients 106(including the client server 110) can be via secure transactions, suchas PKI encrypted transactions. Functionality of a federated controlmechanism of the server 102 is described later with reference to FIG. 6.

It will be noted that the client server 110 is distinguished from theclients 106 for illustrative purposes only. Further, elements of theclient 110 serve as illustrative embodiments of elements shown inclients 106. For example, the address book 114 serves as an example of acontacts datastore 118 and may be implemented as a proprietary datastoresuch as a Yahoo® e-mail address book or an internal contact listcustomized for the system 100. Similarly, the CIS 116 may or may not bean exemplary embodiment of the profile datastore 122 and may comprise,among other things, attributes associated with a subscriber and/orpermission settings. In other embodiments, an address book and/or a CISare optional or left unpopulated.

FIG. 2 depicts a system 200 that provides permissions for query accesscontrol based on attributes. The system 200 may be similar to the system100 depicted in FIG. 1. The system 200 gives a queried subscriberdiscretionary control over attributes data via permissions. The system200 includes a server 202, a first or querying client (party) 204, asecond or queried client (party) 206, and one or more client agent 208.

In an illustrative embodiment, the queried client has attribute data onlocal or mobile storage mediums that is not maintained on the server.Other clients may require such attribute data when the queried client islogged-off, shut-down, or otherwise unavailable. When a first orquerying client 204 contacts a server requesting attributes from asecond unavailable queried client 206, the request if forwarded to theone or more client agents 208 to obtain the attribute.

The server 202 may comprise one or more servers, in an applicable knownor convenient arrangement. In an illustrative embodiment, the server 202maintains permissions for all of the clients. While the server 202 maystore attributes temporarily (or as part of a forwarding process to aquerying client), the attributes may be primarily stored in adistributed fashion on the clients so as to, for example, free upresources on the server 202 or avoid centrally stored data.Alternatively, one or more client agents 208 stores permissions and/orattributes of the queried client 206. Thus, in various embodiments,permissions for access to the attribute may be on the server 202, clientagent 208, or variations thereof.

FIG. 3 depicts an embodiment of the system 300 in which there areseveral client agents 308, 310, 312 in contact with a server 302, whichis additionally in contact with a querying client 304 and a queriedclient 306. Where a querying client 304 requests an attribute from aqueried client 306 via a server, and the queried client 306 isunavailable, the server forwards the request to one or more clientagents 308, 310, 312. The client agents may be contacted simultaneously,or in an order specified by the queried client's 306 permissions andattributes, in an order specified by the server 302, or some otherorder. For example, where the queried client's computer is logged-off orturned off, the server contacts (i.e., forwards the request to) a firstclient agent 3-1 308, and then client agent 3-2 310, and then clientagent 3-N 312, until an available client agent is found. The server 302may obtain permissions and/or attributes from one or more of the clientagents 308, 310, 312, allowing the querying client 304 who satisfiespermissions to obtain attributes from a queried client 306, even whenunavailable.

II. Client Agent

A client agent is a client that serves as an agent for a queried (orsecond) client. In this manner, an agency relationship may beestablished between or among a plurality of clients using a serversystem, such as the system illustrated in FIG. 1. A client agent may ormay not store permissions and/or attributes of a particular queriedclient and respond to forwarded requests for attributes of the queriedclient when the queried client is unavailable. A client agent may storeattributes and permissions, only attributes, only permissions,attributes and permissions from any number of different clients,encrypted or fragmented attributes and/or permissions, or anycombination, thereof. The client agent may have access to the attributesand/or permissions, limited access to data in the attributes and/orpermissions, or no access. In many embodiments, the agency relationshipis essentially invisible to the client agent. Moreover, the client agentmay be no different from any other client in the system (i.e., everyclient could potentially be a client agent, depending upon theembodiment, implementation, and/or client capabilities).

In some embodiments, attributes associated with a queried client arestored on one or more client agent, while permissions are stored on theserver. In some embodiments, attributes and permissions are stored onclient agents and implemented by the server. In some embodiments,attributes are stored on client agents and permissions are stored onclient agents and the server, implemented by the server. In oneembodiment, only permissions may be stored on a client agent, while theattributes are securely stored in a server or computer in communicationwith the server. Permissions from the queried client or correspondingclient agents are required to access these attribute data. Otherarrangement will be apparent to one skilled in the art.

In many embodiments, attributes and permissions may be stored inencrypted, fragmented, password or token protected, or other form toprevent client agents and other unauthorized clients from accessing thecontents of stored attributes and/or permissions.

One or more client agents may be associated with any one or moreclients. For example, each client may store (or host) permissions and/orattributes from a plurality of other clients on a server system.Alternatively or in addition, a particular client's permissions and/orattributes are hosted by a plurality of other clients. Permissionsand/or attributes can be grouped, divided, or separated by anydistinguishing feature and hosted on different clients to maintainseparation.

In an exemplary operation referring to FIG. 3, when a “querying” or“first” client 304 contacts the server 302 requesting attributes of thequeried client 306, permissions and/or attributes can be provided by oneor more client agents, e.g., 308. This arrangement is of particularvalue when the queried client 306 is unavailable, such as off-line withrespect to the server 302, shutdown, logged off, unplugged, crashed, orotherwise unable to communicate permissions and/or attributes with theserver 302.

In this manner, a querying client 304 contacts the server 302, whichfirst attempts to contact the queried client 306, and if unavailable,then contacts the client agent, e.g., 308, for permissions andattributes. If the querying client 304 has permission, the attributesare provided from the client agent, e.g., 308, or from another clientagent, e.g., 310, 312. In this manner, personal, privileged, orotherwise sensitive permissions and attributes are made available toquerying clients, while being isolated from the server.

III. Permissions and Attributes

Permissions include data entries specifying attribute-sharingpermissions between or among different clients of a server system.Permissions may be in a permissions datastore for storing data entriesspecifying attribute-sharing permissions between clients. The datastoremay be on a server, on a client or client agents, or a combinationthereof.

In an illustrative embodiment, attributes are stored on a client agent,while permissions are stored on the server or on a computer incommunication with the server. Permissions could also be stored onclient agents, e.g., while the attributes were in a secured part of theserver or computer in communication with the server.

One or more client agents may be associated with any one or moreclients. Permissions and/or attributes may be stored on the same clientagent or different client agents. Each client may host permissionsand/or attributes from a plurality of other clients on a server system.In another example, a particular client's permissions and/or attributesare hosted by a plurality of other clients. Permissions and/orattributes can be grouped, divided, or separated by any distinguishingfeature and host on different clients to maintain separation.

Client agents may be workstations, mainframe computers, servers, mobilecommunication devices, or other computers having or connected to astorage medium. One or a plurality of client agents can be used to hostpermissions and/or attributes from any number of clients on a serversystem. Alternatively, a network of client agents supports clients basedon location, content, etc. In a further embodiment, some or all clientsare client agents, perhaps without being aware, as in the case of aworkstation environment where each client stores permissions and/orattributes one or more local mediums.

Client agents may synchronize with the clients they serve, via theserver, at periodic intervals, upon demand, in real time, or anycombination or variation, thereof, as used for backing-up computer data.Permissions are generally date stamped. Attributes may also be datestamped.

Any or all client permissions and attributes may be stored on one ormore client agents in an encrypted form, such that a client agent, whilestoring the permissions and/or attributes of one or more other clients,cannot access the content.

Examples of particular permissions and attributes are described below.Other embodiments will be apparent to the artisan.

A. Permission Sets

The permission sets controls what attribute sets a client 204, 206, 208of the system 200 will share with other clients, what attribute sets aclient will enable other client to query, whether other client willreceive contact information of a client who matches a query request, andthe content of query requests a querying client will receive.

Datastores for storing permissions settings may include tables forcontrolling access to attributes. Such tables can include a user table,an access table, a privacy table, and a query access table.

The user table may include fields for user identification, user name,and other user information. The user table may include a number ofattributes including, but not limited to, user name, anniversaries, homeaddress, business address, home phone number, home fax number, cellphone number, business phone number, email addresses, wish lists,clothing sizes, favorite colors, favorite foods, and the like.

Exemplary methods for adding and/or editing the permissions orattributes are described with reference to U.S. Pat. No. 7,461,071,which is incorporated by reference. In an illustrative embodiment, asubscriber adds or edits a set of permissions applicable to one or moreother subscribers known to the subscriber as contacts. For example, asubscriber may add a new phone number and allow contacts in thesubscriber's address book access to that phone number. The subscriber'saddress book may be stored in any applicable format including thosediscussed herein. In another embodiment, a subscriber adds or edits thepermissions associated with queries including, but not limited to, thesubscriber's privacy status and/or query accessibility.

B. Attribute Sets

The attribute sets comprise entries having attributes associated withthe clients of the system 200. The attributes may include, but are notlimited to, first name, last name, anniversaries, home address, businessaddress, home phone number, home fax number, cell phone number, businessphone number, email addresses, wish lists, clothing sizes, favoritecolors, favorite foods, and the like.

Attribute sets may or may not include a contact datastore, which storesinformation associated with a subscriber's contacts. The contactdatastore may comprise a number of data entries wherein each entryincludes one or more attributes associated with a contact known to thesubscriber. A contact datastore entry may include additional attributessuch as the type of contact including but not limited to a business orpersonal contact. Contact datastores can be divided and stored on anynumber of clients.

Each attribute in the attribute sets may correspond to one or morepermissions settings in the permission sets. A client may manipulatepermissions in various configurations in order to restrict thedistribution of attributes associated with the client. For example, aclient may divide the attributes into categories such as personal andbusiness and designate other subscribers known to the subscriber as apersonal or business contact. Consequently, other clients designated aspersonal contacts are granted permissions to the personal attributeswhereas the business contacts will have access only to the businessattributes.

In one example, a client may set the permissions associated with anattribute such that one or more other a designated clients will beupdated when the client changes the content or value of the attribute.Further, a client may set permissions to restrict what other clientswill receive if the client's attributes match the query criteria. Forexample, the client may select a private status to receive notice ofsearch queries matching the client's attributes and decide whether thequerying parties will receive any result from the client.

C. Profile Datastore

The profile datastore 122 may include one or more attributes associatedwith a subscriber (referring to FIG. 1). For example, a profiledatastore may comprise the subscriber's name, home address, e-mailaddress, favorite food, high school attended, and the like. In oneembodiment, the profile datastore 122 may include permission controldata associated with each profile attribute. Moreover, both the profiledatastore and the contact datastore may be left unpopulated.

D. Access Tables

As described above, datastores for storing permissions settings mayinclude tables for controlling access to attributes. Such tablestypically include an access table, a user table, a privacy table, and aquery access table.

Access tables may include fields, such as grantor UID, attribute ID, andgrantee UID. In one embodiment, a subscriber identified by a grantor UIDgrants a second subscriber identified by a grantee UID access to certainattributes identified by the attribute ID. For instance, a firstsubscriber identified by the grantor UID 000001 allows a secondsubscriber identified by grantee UID 000002 access to the firstsubscriber's attribute identified by attribute ID 000002. In oneembodiment, if a grantor has granted a grantee access to certainattributes, the grantee has query access to those attributes. In anotherembodiment, if a grantor has granted a grantee access to certainattributes, the grantee receives updates of those attributes when thegrantor makes changes to the attributes. The attributes identified bythe attribute ID may include personal, privileged, or other sensitiveattribute data, e.g., as described herein.

III. Maintaining Secure and Current Permissions and Attributes

Maintaining the accuracy and integrity of data, including permissionsand attributes, allows the system and methods to optimally protect anddistribute/share client permissions and attributes.

In some embodiments, upon receiving a query from a querying client, aserver contacts multiple client agents to obtain permissions and/orattributes. The server may then select the most recent permissions orattributes from among those stored by the client agent, e.g., using atime stamp placed on the relevant information. Time stamps are wellknown in the art.

Changing permissions and/or attributes may be associated with one ormore security features such as, e.g., a one-time password, aconfirmation number, a token, and the like. The server may check/verifysuch security features in selecting the permissions and/or attributes toapply.

Where unauthorized access to the server system or other tampering issuspected, the integrity and/or accuracy of the most recent permissionsand attributes may be compromised, or assumed compromised. It may thenbe preferable to select permissions and/or attributes other than themost recent. In such cases, the server may select the permissions and/orattributes that predate the unauthorized access to, or suspected breachor vulnerability of, the system.

Where identical permissions and/or attributes are stored on multipleclient agents, the server may select the permissions and/or attributesthat are present on a plurality of client agents but ignores permissionsand/or attributes present on one client agent, even if the latter set ofpermissions and/or attributes is more recent. In this manner, the systemand methods verify permissions and prevent a client agent from changinga queried client's permissions and/or attributes, e.g., without consent.

Where different permissions and/or attributes are stored on differentclient agents, the server may apply any of the above or other selectioncriteria to each permission or attribute. For example, the server mayselect certain permission from a workstation or hand-held mobile devicebased on the most recent date stamp, while selecting other permissionsor attributes predating an unauthorized access. Permissions and/orattributes may be selected by many criteria, with a general goal ofmaintaining accuracy and security of the data.

IV. Operational Embodiments

In one operational embodiment, where the server 302 in FIG. 3 (or clientserver as shown in FIG. 1) does not store a copy of a queried client's306 permissions and/or attributes, they may be stored on one or moreclient agents, 308, 310, 312, i.e., a client that serves as an agent foranother client. A querying client 304 may contact the server to requestand attribute, such as a customer's contact information, from a secondqueried client 306. The particular attribute may be on the queriedclient's 306 local hard drive, where, e.g., an email, media, or otherprogram stores user settings.

Upon finding that the queried client has logged-off his workstation oris other wise unavailable, the server forwards the request to one ormore client agents 308, 310, 312 to obtain the most recent permissionsfor accessing the queried client's address book. The permissions may ormay not be, by way of example but not limitation, date stamped. Thequerying client satisfies the most recent permissions and is allowed toaccess the address book, which may stored on the same client agent 308or a different client agent 310, 312. The distribution/sharing of theattribute and identity of the querying client is reported to the queriedclient, e.g., via email, instant message, text message, etc.

In a second operational embodiment, a querying client 304 contacts theserver to request an attribute, such as a customer's contactinformation, from a queried client 306. The attributes and permissionsare on the queried client's 306 local hard drive, the permissions arealso on a client agent 308. The queried client 306 workstation issuspected of unauthorized access.

Upon receiving a request for an attribute of a particular queryingclient 304, the server 302 checks permissions on the queried client's306 workstation. The permissions were recently updated to allow thisparticular querying client to access this particular attribute. Inresponse to the unauthorized access, the server 302 is configured toautomatically contact a client agent to confirm permissions when arequest is made to this queried client. The server 302 contacts theclient agent 308 storing the queried client's 306 permissions, whichpredate the unauthorized access. This particular querying client 304 isnot permitted access to the attribute based on the earlier permissions,which the server recognizes as more reliable. The server does not allowaccess to the attribute.

The request by the querying client can be reported to the queriedclient, log information can be sent to the server, and the systemadministrator can be alerted to the suspicious activity. Theseoperations are generally considered optional, even where implementationof such operations is desirable.

In a third operational embodiment, a queried client's 304 local harddrive crashes, causing the loss of important attributes that the queriedclient neglected to back-up. According to the present system, one ormore client agent 306, 310, 312 stores the queried client's 304information, enabling the queried client to recover the attributes.

In a fourth operational embodiment, a queried client's 304 local harddrive crashes, causing the loss of important attributes, such asaddress, website links, and account information. These attributes mayhave been backed-up during the server systems period back-up routine;however, this is Friday evening and IT personnel are unavailable. Thepresent system and methods forwards the request to one or more clientagents 306, 310, 312, which store the queried client's 304 information.Via permissions, the queried client is enable to recover the attributesand the queried client, as well as other querying clients, continue tohave access to the attributes.

These operation examples illustrate use of the present system but arenot intended as limiting. Many further uses will be apparent to oneskilled in the relevant art.

V. Exemplary Features of Further Illustrative Embodiments

A. Servers

The system generally includes a server to which the clients areconnected. In some embodiments, the server 102 (FIG. 1) comprises one ormore computer-readable mediums (which includes a medium used by a knownor convenient type of storage device that is accessible by a processor).As used in this paper, the term “computer-readable storage medium” isintended to include only physical media, such as memory. As used in thispaper, a computer-readable medium is intended to include all mediumsthat are statutory (e.g., in the United States, under 35 U.S.C. 101),and to specifically exclude all mediums that are non-statutory in natureto the extent that the exclusion is necessary for a claim that includesthe computer-readable medium to be valid. Known statutorycomputer-readable mediums include hardware (e.g., registers, randomaccess memory (RAM), non-volatile (NV) storage, to name a few), but mayor may not be limited to hardware. The server 102 may include varioushardware and/or software components, as described herein. The network104 may be the internet, an intranet, or some other applicable known orconvenient network.

The server may also be part of a distributed computing environment,wherein tasks are performed by remote processing devices linked througha communications network. The server may be coupled to one or more datastores, which may be internal to, directly connected to, and/or a partof the server. In some embodiment, the data stores may be separate orremote from the server and may communicate to the server through anetwork such as the network 104 illustrated in FIG. 1. The data storescomprise one or more computer-readable mediums, as described above. Inone embodiment, the data stores may comprise an SQL database that storessubscriber information, attribute sets, permission sets, and atransactions log for the system.

Permissions may reside on the server, the server along with a client,the server along with one or more client agent, or permutations andcombinations, thereof. As used herein, attributes generally reside onstorage medium separated from the server.

B. Client Servers

Client servers are common in large server-based network systems, whereit is often desirable to distribute server functions among severalserver devices, which maintaining some level of centralized control. Theclient server 110 (FIG. 1) may include various hardware and/or softwarecomponents, as with any server. In some embodiments, the clients 106include a user interface 112, a contact datastore 120, and a userprofile datastore 122. The user interface 112 facilitates theinteraction between the system and a subscriber of the system. Thesubscriber may use the interface 112 to update profile attributes orcontact information. The user interfaces may include, but is not limitedto, an internet/web interface, a mobile phone and the like. As notedelsewhere, features described with reference to any one of the clients106, 110 may be applicable to all or a subset of the clients 106, 110.

C. Mobile Devices

The server 202 may communicate with handheld devices, multiprocessorsystems, microprocessor-based or programmable consumer electronics,network PCs, minicomputers, mainframe computers, wireless devices, andthe like. One or more permissions and/or attributes may be stored onsuch devices. One or more permissions and/or attributes may be also berequested from such devices.

The mobile devices 108 may include various hardware and/or softwarecomponents, as described herein. In many embodiments, clients 106 may bemobile devices. The 108 synch with the client 110 in a manner that isknown in the computer arts. For example, the mobile device 108-1 may beby way of example but not limitation a mobile phone, and the mobiledevice 108-2 may be by way of example but not limitation a PDA, both ofwhich can synch with, by way of example but not limitation, a Mac OS XAddress book on a user's computer (e.g., the client 110) through aniSync mechanism, which is known in the computer arts. The client 110would then update local datastores based upon the results of the iSync.Comparable technologies exist for various address book types and variousoperating systems, including but not limited to Blackberry and Palm.

VI. Dynamic Permission Table

In the example of FIG. 1, the system 100 includes a dynamic permissiontable 124. In an embodiment that includes content blobulation (see,e.g., FIGS. 4-6), the dynamic permission table 124 can include a recordof permissions granted dynamically. The dynamic permission table can bepart of a permission table in the server 120, or it could be stored in adistributed fashion, or stored on some other server. In a system thatenables reblobulation, for a machine that is being repopulated withattributes that are stored in a distributed manner, the machine canobtain the attributes automatically from users that accepted dynamicpermissions, or the users who accepted dynamic permissions could berequested to provide the attributes preferentially over those users whosimply have passive permission to access the attributes.

FIG. 4 depicts a conceptual view of a system 400 for individualized datasharing. The system 400 includes a content owner 402, a contentdatastore 404, a passive permissions table 406, a permitted user 408, adynamic permission 410, and a content blob 412.

In the example of FIG. 4, the content owner 402 can grant permissions tocontent in the content datastore 404. Permissions are stored in thepassive permissions table 406, which can be stored at a permissionsserver (not shown). The passive permissions table 404 can be centralizedor distributed, which means the permissions server can be implemented ina centralized or distributed fashion. For example, the passivepermissions table 406 can be stored at a server or the content ownercould maintain a subset of the table locally.

The content datastore 406 can also be centralized or distributed.Content in the content datastore 406 can be stored locally at one ormore machines of the content owner 402. In some cases, all of thecontent of the content datastore 406 is stored at one or more machinesof the content owner 402, though, particularly if a machine of thecontent owner 402 goes down, it may be desirable to store some or all ofthe content of the content datastore 404 elsewhere. Depending upon theimplementation, it may also be the case that a content owner does notstore any, or only stores a subset, of the data in the content datastore404 on a machine of the content owner 402. In a specific embodiment, thecontent datastore 406 includes content saved on other machines as well,such as at a machine of the permitted user 408. Redundancy of content ofthe content datastore 404 can facilitate recovery in the event of dataloss at a machine of the content owner 402, a machine of the permitteduser 408, or at other machines (typically, though not necessarily, onlymachines that have permission to the content).

The permitted user 408 is able to access relevant content of the contentdatastore 404 if permissions in the passive permissions table 406 areset appropriately. Content could have different permissions fordifferent portions of the content datastore 404. For example, thecontent owner 402 could grant permission to view a work phone number toone user and permission to view a home phone number to another. In orderto keep the content datastore 404 manageable, the fields can be definedexplicitly. One or more “catch-all” fields are also possible, but animplementation that at some arbitrary point allows permissions to beassociated with any particular field is probably desirable so that thecontent owner 402 can grant permissions with a desired granularity. Forexample, the content owner 402 might find that there are too few or toomany “catch-all” fields, and redefine fields to achieve the desiredgranularity. In some implementations, per-field granularity may or maynot be possible despite the apparent advantages. There can be advantagesto grouping fields for ease of management, either as a system design orin accordance with configurable user preferences.

Advantageously, the content owner 402 can grant active permissions onthe fly. These dynamic permissions can be granted whenever a permitteduser is to be granted access to a content blob. In the example of FIG.4, the dynamic permission 410 represents one such grant of permission tothe permitted user 408 for the content blob 412. As is illustrated, thedynamic permission 410 and the content blob 412 are sent from thecontent owner 402 to the permitted user 408. The content blob 412 caninclude a transfer of the content itself, or a link to the contentassociated with the content blob 412.

It should be noted that the permitted user 408 may or may not havepermissions set in the passive permissions table 406 for content in thecontent datastore 404. However, there are advantages to sending thedynamic permission 410 to the permitted user 408, where the permitteduser 408 is already permitted to access content in the content datastore404 through the passive permissions table 406; so this is presumed inthe example of FIG. 4. For example, with both active and passivelygranted permissions, content can be automatically updated when thecontent is changed, assuming the system is so configured and/or thepermitted user 408 accepts automatic updates. As a specific example,when the content owner 402 adds new pictures to a photo album to whichthe permitted user 408 has access, the content owner 402 can send thedynamic permission 410 and the content blob 412 (including either thenew pictures or a link to the photo album).

Reblobulation is also possible by maintaining dynamic permissionreceipts, and sending content to the owner upon request. For example,the permitted user 408 could maintain a receipt of the dynamicpermission 410, stored locally in association with the content blob 412or provided to a dynamic permission table in a remote location. If thecontent owner 402 loses content associated with the content blob 412,either because it is deleted or a machine fails, the content owner 402can request reblobulation from the permitted user 408. Depending uponthe implementation, the permitted user 408 could provide the contentautomatically upon request, either by explicitly granting permission toreblobulate by accepting the dynamic permission 410 or by design(perhaps without the permitted user 408 being given a choice to assistwith reblobulation). In this way, those users that accepted dynamicpermissions are the pool from which agents (see, e.g., FIGS. 2 and 3)can be drawn. Alternatively, the permitted user 408 could grantreblobulation permission upon receiving a request for reblobulation,either by requiring approval upon receipt of the dynamic permission 410or by design (so that the permitted user 408 is always aware of requestsfor reblobulation). Thus, sharing content is also a convenient backupfor the content.

In an example where the content owner 402 loses data and mustreblobulate, the content owner 402 can access the passive permissionstable 406 to find out who has access to content in the content database404. Depending on the implementation of the system 400, the contentowner 402 can assume that the permitted user 408 received the dynamicpermission 410 at some previous time, and request reblobulation from thepermitted user 408.

In another implementation, the passive permissions table 406 can includea field associated with an attribute that indicates whether dynamicpermission was granted for the attribute. In this implementation, thecontent owner 402 would modify the passive permissions table 406accordingly (either by writing to the table or reporting to a permissionserver that writes to the table), or the permitted user 408 would reportreceipt and/or acceptance of the dynamic permission 410 to a permissionserver that writes to the table. (It is theoretically possible that thepermitted user 408 could write to the passive permission table 406directly, but this is probably undesirable given a presumed securityconstraint of having the content owner 402 control permissions.) Withthis implementation, the content owner 402 could, for example, only, orpreferentially, request reblobulation from users who received and/oraccepted dynamic permissions. Thus, it is possible for the permitteduser 408 to be granted passive permission (and not assist inreblobulation) or implicitly volunteer to assist with reblobulation byaccepting the dynamic permission 410. Also, the content owner 402 candecide whether to grant permissions based upon whether the permitteduser 408 agrees to assist with reblobulation by accepting the dynamicpermission 410. That is, some permissions may require acceptance of thedynamic permission 410, while others might not. Advantageously, thebackup of content enables automatic restoration. That is, restorationthat happens immediately upon startup of an appropriate machine from auser that accepted dynamic permission to the content (perhaps includingother machines of the content owner 402).

Sharing can be non-exclusive or exclusive, though exclusive sharing mayrequire significant modifications to applications. For example, if youshare a Word document with a user, the user is typically able to saveand transmit the document as desired. With appropriate configurations toan application, however, the document can be made “unsavable” in someother format, or have other characteristics. This may be desirable incases where other users can request reblobulation of content to whichthe user is permitted and the permitted user 408 serves as an agent.

FIG. 5 depicts flowchart 500 of a method for utilizing dynamicpermissions for content. The method is organized as a sequence ofmodules in the flowchart 500. However, it should be understood thatthese and modules associated with other methods described herein may bereordered for parallel execution or into different sequences of modules.

In the example of FIG. 5, the flowchart 500 starts at module 502 where afirst user grants passive permission to a second user. The granting ofpassive permission can include updating, or causing to be updated, apassive permission table. The exact implementation of the passivepermission table is configuration-specific, but should includesufficient data to enable an attribute to be associated with apermission granted to a user. The granularity of the attributes isimplementation and/or configuration-specific, but it is expected that acontent owner will have the ability to identify content with arelatively high degree of granularity. Permissions can be associatedwith a single user or groups of users, and could be associated with nouser at all if the permissions table includes more attributes than acontent owner has granted permission for (though an implementation couldrequire that the content owner grant permission in order to have anentry in the passive permission table). Generally, an attribute can beidentified with an attribute ID and users can be identified with(individual and/or group) UIDs, though the identification can be in anyapplicable known or convenient form. The content owner will normallyhave control over the passive permissions table (or a portion thereof ifmultiple content owners are represented in the passive permissionstable), but the passive permissions table need not be stored on amachine of the content owner. For example, the passive permission tablecould be stored on a centralized or distributed permission server havingan applicable known or convenient configuration or functionality.

In the example of FIG. 5, the flowchart 500 continues to module 504where a first user grants dynamic permission to the second user. Thefirst user can send the dynamic permission directly to the second userin a known or convenient manner (e.g., an electronic message). The firstuser can also trigger some other device, such as a permission server orsome other server, to send dynamic permission on the first user'sbehalf. Although the first user is the source of the dynamic permission,it is implementation- and/or configuration-specific where the dynamicpermission is generated or through which devices the permission passesto reach the second user. Since the first user is the source, it isintended to be implicit that the first user generating and sending thedynamic permission includes generating and/or sending on behalf of or inaccordance with instructions of the first user. By dynamic, it isintended to mean that the first user grants permission that can bereceived in due course by active attempts to send a notification to thesecond user. For example, the dynamic permission could be sent in anemail. It should be understood that whether the second user actuallysees the dynamic permission will depend upon whether the second userchecks the relevant inbox (e.g., an email application). Also, if themedium through which the permission is sent is disabled for some reason,including if the delivery requires that a particular machine of thesecond user be on, multiple attempts can be made to deliver the dynamicpermission. Alternatively, a notification of dynamic permission could besent, requiring the second user to take some action to view or acceptthe dynamic permission, such as by logging onto an account. In anembodiment, the order of modules 502 and 504 can be switched, thoughthis is generally true of any applicable module in the flowchartsillustrating methods in this paper.

In the example of FIG. 5, the flowchart 500 continues to module 506where the first user gets acknowledgement of acceptance of the dynamicpermission from the second user. It is possible that a system may beimplemented such that module 506 is omitted or optional, but thiseliminates some of the advantages of utilizing a dynamic permission. Forexample, the first user may not know if the second user is aware of thegrant of permission. Also, in an implementation that enablesreblobulation of content that was sent to users who accept dynamicpermission, it would be desirable for the first user (or a server thatacts on behalf of the first user) to be aware that the second user isable to participate in a reblobulation attempt. It is implicit that aserver that receives the acknowledgement and acts on behalf of the firstuser means that the first user gets the acknowledgement, even if thefirst user does not explicitly receive the acknowledgement. Thus, “firstuser gets acknowledgement” is intended to include explicit receipt bythe first user and receipt on behalf of the first user. The failure toget acknowledgement could be reason to, or could automatically resultin, rescinding passive permission to the content and/or related content(e.g., failure to receive acknowledgement of dynamic permission to aphoto could result in passive permission to the photo being rescindedand/or passive permission to a photo album with which the photo isassociated being rescinded). In an embodiment, the order of module 502could be after that of module 506, though this is generally true of anyapplicable module in the flowcharts illustrating methods in this paper,and could be dependent upon getting acknowledgement.

In the example of FIG. 5, the flowchart 500 continues to module 508where the first user sends a content blob associated with the dynamicpermission to the second user. Here, what is intended by “associatedwith the dynamic permission” is that the dynamic permission is tocontent in, or in a link that is in, the content blob. The use of theword “blob” is intended to indicate that any applicable known orconvenient content could be used. In an embodiment, the modules 506 and508 could be combined, though this is generally true of any applicablemodule in the flowcharts illustrating methods in this paper, such thatthe dynamic permission and the content blob are sent simultaneously.

In the example of FIG. 5, the flowchart 500 ends at module 510 wherepermissions are maintained so as to enable reblobulation. One advantageof requiring acceptance of dynamic permissions is that, if the system isso configured, the acceptance can indicate that the second user iswilling to aid reblobulation. Thus, by sharing content, the first usercan essentially backup the content, and reblobulate a machine if theircontent is locally lost. Another advantage is that the second user willnot have old data reblobulated with new data without first obtainingdynamic permission to the new data. So, for example, the second usercould archive old data before receiving dynamic permissions to new datathat might over-write the old. Also, some users may not be comfortablewith allowing a system to reach inside their machine without permission,at least in part due to concerns about privacy; so the second user maywant the comfort of knowing that they do not have to accept dynamicpermission to content that will overwrite their data. That said,acceptance of dynamic permission could include, depending upon theimplementation, permission to update the content at a later time so asto keep shared data consistent and up-to-date. It may be noted thatreblobulation can also be accomplished using passive permissions, sincethe passive permissions also identify users who have access to content.

FIG. 6 depicts a flowchart 600 of an example of a method forself-management of personal information sharing. In the example of FIG.6, the flowchart 600 starts at module 602 where a first user storesattributes. This can include storing any attributes that the first userwishes, including that which the first user has no intention of sharing.The user is given control over their own information, which is anadvantage of non-centralized storage of personal information.

In the example of FIG. 6, the flowchart 600 continues to module 604where the first user configures a risk profile scheme. The configurationof a risk profile scheme involves, for example, setting secretinformation permissions to never, such that the information is notshared with anyone; setting private information permissions, such thatonly specific entities have access to the information; setting personalinformation permissions, such that only (real) friends have access tothe information; setting business information permissions, such thatbusiness contacts have access to the information; and setting publicinformation settings, such that anyone has access to the information.Secret information can be shared with other devices that the first userowns. For example, the first user might share information between thefirst user's desktop and mobile phone. Private information might includesensitive data that is only shared when it is necessary. For example, abank might require that you know your account number. So you might sharethe account number with the bank, and perhaps routing information with amerchant or other party. Personal information might include that whichyou want your friends to know, such as your home phone number orbirthday. Business information might include that which you wantbusiness contacts to know, such as your mobile phone number or officeaddress. Public information settings might include your name, if youwant people to be able to search for you. Advantageously, thesecategories are simply examples, and the first user can have many morecategories, and assign permissions for particular attributes on anas-needed basis (e.g., Mother's maiden name when that is a requiredaccess code). Thus, configuring the risk profile scheme is not apermanent setting: the first user can dial privacy up, dial privacydown, and distribute attributes as a group or individually as desired.The system can facilitate almost any number of levels of “friend” basedupon how much information a user wants to share.

In the example of FIG. 6, the flowchart 600 continues to module 606where the first user grants permission to attributes in accordance withthe risk profile scheme. The permissions can be granted to anindividual, a group, a community, or some other entity. The party towhich permissions are granted can be identified explicitly by the firstuser or the party can contact the first user after the first user sharespublic attributes that enable the second user to find the first user.Since the first user grants permissions to attributes that are initiallystored locally, and which can be stored in a distributed fashion as theattributes are distributed, the attributes can be stored in a scalablelarge, networked, distributed community. The technique facilitates,e.g., a stateless, independently managed permission model for lowlatency exchanges that is not disruptive to other data models. No userdata need be stored by a federated exchange system, which can beconfigured to cache “in-flight” transactions only and can be deployedinside a client data center without data being stored at an externalvendor. Advantageously, the technique can enable the deployment of asingle, secure federated exchange for personal or business informationthat is distributed, implements changes to data automatically, andensures data validity is not an issue.

In the example of FIG. 6, the flowchart 600 continues to decision point608 where it is determined how the first user responds to federatedcontrol. The federated mechanism could be implemented by the community,or by a third party exchange service, such as the exchange service thatfacilitates the creation of the distributed attribute system. Thefederated mechanism could be triggered by going to a particular website,or indicating membership in a particular community in such a manner thatthe federated control mechanism is aware of the membership (e.g., afederated exchange server could enable the first user to check boxesassociated with parties that are under federated control). If it isdetermined that the first user responds affirmatively to federatedcontrol (608-Y), then the flowchart 608 continues to module 610 wherethe second user requests additional permissions. The federated controlmechanism can include what amounts to an interface to a particularcommunity that has certain requirements for login. For example, if thefirst user wishes to share attributes with a social network, the socialnetwork may have username and password requirements. So the federatedcontrol mechanism, which knows the requirements, may request that thefirst user provide a username and password (the user could also grantpermission to a username and password, if the attributes are already inthe first user's profile, but the federated mechanism would notnecessarily be aware of such data). Presumably, if the first userrefused to grant permissions to the username and password attributes,the first user would be required to login normally when visiting theonline community.

The federated control mechanism can also request permissions to optionalattributes. For example, a user may be a member of an airline mileageprogram that gives miles for staying at certain hotels. If the userbecomes a member of a hotel community, the federated mechanism couldrequest the airline mileage program number, which can be used to creditthe first user for staying at the hotel. An online social network mighthave options for a great deal of personal information, which thefederated control mechanism could request permissions to. Whether thepermissions are granted would be up to the first user, and the responsecould be essentially automated to grant permission to public informationwhen requested, and refusing to grant permission to more privateattributes, unless the permission is explicit.

It is also possible to architect federated control mechanisms betweencommunities. In such a case, communities could automatically sharecertain attributes with one another. It may be desirable to enable thefirst user to grant non-transferable permissions, if such an exchange ofdata is not desired. A less intrusive architected federated controlmechanism between communities could simply enable communities torecognize certain attributes as the same. For example, if twocommunities can store the birthday of the first user, the birthdayattribute could be recognizable by both, either because the communitiesmake certain that their internal structure can accomplish this goal, orbecause the federated mechanism creates an alias for the birthdayattribute that is recognizable to a community, and grants permission tothe community to the alias. In this way, the first user could share thebirthday attribute with a community that is under federated control, andthe attribute would be recognized as a birthday. Advantageously, thisenables the first user to apply one permission model across their entiredigital world (or at least that portion that is under federatedcontrol), including communities (e.g., Yahoo, Ebay, MSN, Terra/Lycos,LinkedIn), corporations (e.g., banks, utilities, corporate HR/payroll),carriers (e.g., Vodaphone, Cingular, 02, DoCoMo), professionals (e.g.,lawyers, doctors, accountants, consultants), networked individuals(e.g., mobile individuals with a connected desktop, laptop, mobile, orPDA), etc. A federated control mechanism can facilitate an interchangeof rules and data via standards, such as REST, XML, and HTTPS viadocumented APIs.

In the example of FIG. 6, the flowchart 600 returns to module 606 wherethe first user grants permission to attributes in response to therequest for additional permissions. If a community does not have afederated control mechanism, or if the exchange service does not know ofthe community requirements, then the first user would not be able torespond affirmatively to federated control; or if the first user alreadyprovided the necessary or optional permissions, or is not interested inresponding to the federated control mechanism (608-N), then theflowchart 600 continues to module 612 where the first user maintainsattributes. Maintaining attributes can includes storing additionalattributes (602), reconfiguring the risk profile scheme (604), andgranting additional permissions in accordance with the risk profilescheme (606). Changes to attributes that are stored by others can bepushed from the first user, or the parties might receive notices thatupdates are available, and the parties can pull the new attributevalues.

In the example of FIG. 6, the flowchart 600 continues to module 614where the first user content blobulates. Content blobulation is intendedto mean that the first user grants dynamic permissions to content blobs.It may be noted that a system could require or optionally enable contentblobulation for all attributes, though it would be relatively hard torequire blobulation of all attributes if the attributes are public(since you would presumably have to send the attributes to everyone inthe public domain). So the choice of whether and how much blobulation isimplemented can have an impact on how much customization is possiblewith the risk profile scheme. No presumption is made to how muchblobulation must be or can be used in the example of FIG. 6. Sharinginformation can build a community, but controlling the information,including whether data is received through the distribution channels ofthe system, can build trust. By first forming a connection via afederated exchange, then receiving content blob updates from those withwhom connections are formed, the federated exchange can help build trustamong users.

Content blobulation can be conditional based upon various factors, suchas location, receiving a new level in a loyalty program, etc. So a usercan be updated based upon factors unique to them, rather than or inaddition to the first user updating old attributes. In addition toenabling the first user to distribute attributes and essentially backthem up in a distributed fashion, automatic updates can be particularlyadvantageous for, e.g., customer service contact information, or toprovide updates from companies without an active customer serviceorganization when content is added to a website or other datastore, orto share loyalty program information, such as from merchants andairlines. The sharing of information can be based upon various data,such as current location of a mobile device or known schedules (e.g.,flights to Paris from JFK or arriving at a hotel could trigger localizedupdates from nearby businesses). Since users control their personalinformation, if a user shares information with, e.g., Starbucks,Starbucks can send localized updates or let the first user know whenthey are nearby. In this way, content blobulation can act as a form ofadvertising, in addition to simply ensuring that contacts have the mostup-to-date contact information. It is not even necessary that contentblobulation provide new data, depending upon how the federated system isimplemented. For example, a user might be able to reblobulate with olddata simply to get a user's attention, though this might be undesirable,depending upon the goals of the federated system.

Content blobulation can be used to provision clients of, e.g., acompany. For example, when a computer is set up for an employee, thecomputer can be blobulated using other computers in the network.Generally, provisioning a computer entails the use of a server thatincludes company information, but that is not necessarily a requirement,and a distributed datastore is a workable option.

In the example of FIG. 6, the flowchart 600 ends at module 616 where thefirst user performs reblobulation. Blobulation can enable reblobulation(or zero-touch restoration without backup) by recalling the computers towhich content has been blobulated. For example, if the first user'scomputer is destroyed and the first user obtains a new computer, simplyby logging into the federated system, the new computer can be populatedwith all of the data that was shared. Where content blobulation wasdynamic (and required other users to accept the content blob), thefederated system can require that the recipients of the content blobreciprocate by providing the content blob when requested by a party withpermission. In this example, the first user is the party withpermission. It may be noted that although the flowchart 600 ends withreblobulation, conceptually the flowchart 600 could return to module 612(or some other module) and continue with maintenance of attributes.

FIG. 7 depicts a system on which a framework for individualized datasharing can be implemented. FIG. 7 depicts a networked system 700 thatincludes several computer systems coupled together through a network702, such as the Internet. The term “Internet” as used herein refers toa network of networks which uses certain protocols, such as the TCP/IPprotocol, and possibly other protocols such as the hypertext transferprotocol (HTTP) for hypertext markup language (HTML) documents that makeup the World Wide Web (the web). The physical connections of theInternet and the protocols and communication procedures of the Internetare well known to those of skill in the art.

The web server 704 is typically at least one computer system whichoperates as a server computer system and is configured to operate withthe protocols of the world wide web and is coupled to the Internet. Theweb server system 704 can be a conventional server computer system.Optionally, the web server 704 can be part of an ISP which providesaccess to the Internet for client systems. The web server 704 is showncoupled to the server computer system 706 which itself is coupled to webcontent 708, which can be considered a form of a media datastore. Whiletwo computer systems 704 and 706 are shown in FIG. 7, the web serversystem 704 and the server computer system 706 can be one computer systemhaving different software components providing the web serverfunctionality and the server functionality provided by the servercomputer system 706, which will be described further below.

Access to the network 702 is typically provided by Internet serviceproviders (ISPs), such as the ISPs 710 and 716. Users on client systems,such as client computer systems 712, 718, 722, and 726 obtain access tothe Internet through the ISPs 710 and 716. Access to the Internet allowsusers of the client computer systems to exchange information, receiveand send e-mails, and view documents, such as documents which have beenprepared in the HTML format. These documents are often provided by webservers, such as web server 704, which are referred to as being “on” theInternet. Often these web servers are provided by the ISPs, such as ISP710, although a computer system can be set up and connected to theInternet without that system also being an ISP.

Client computer systems 712, 718, 722, and 726 can each, with theappropriate web browsing software, view HTML pages provided by the webserver 704. The ISP 710 provides Internet connectivity to the clientcomputer system 712 through the modem interface 714, which can beconsidered part of the client computer system 712. The client computersystem can be a personal computer system, a network computer, a web TVsystem, or other computer system. While FIG. 7 shows the modem interface714 generically as a “modem,” the interface can be an analog modem, isdnmodem, cable modem, satellite transmission interface (e.g. “direct PC”),or other interface for coupling a computer system to other computersystems.

Similar to the ISP 714, the ISP 716 provides Internet connectivity forclient systems 718, 722, and 726, although as shown in FIG. 7, theconnections are not the same for these three computer systems. Clientcomputer system 718 is coupled through a modem interface 720 whileclient computer systems 722 and 726 are part of a LAN 730.

Client computer systems 722 and 726 are coupled to the LAN 730 throughnetwork interfaces 724 and 728, which can be ethernet network or othernetwork interfaces. The LAN 730 is also coupled to a gateway computersystem 732 which can provide firewall and other Internet-relatedservices for the local area network. This gateway computer system 732 iscoupled to the ISP 716 to provide Internet connectivity to the clientcomputer systems 722 and 726. The gateway computer system 732 can be aconventional server computer system.

Alternatively, a server computer system 734 can be directly coupled tothe LAN 730 through a network interface 736 to provide files 738 andother services to the clients 722 and 726, without the need to connectto the Internet through the gateway system 732.

FIG. 7 depicts a computer system 740 for use in the system 700. Thecomputer system 740 may be a conventional computer system that can beused as a client computer system or a server computer system or as a webserver system. Such a computer system can be used to perform many of thefunctions of an Internet service provider, such as ISP 710.

In the example of FIG. 7, the computer system 740 includes a computer742, I/O devices 744, and a display device 746. The computer 742includes a processor 748, a communications interface 750, memory 752,display controller 754, non-volatile storage 756, and I/O controller758. The computer system 740 may be couple to or include the I/O devices744 and display device 746.

The computer 742 interfaces to external systems through thecommunications interface 750, which may include a modem or networkinterface. It will be appreciated that the communications interface 750can be considered to be part of the computer system 740 or a part of thecomputer 742. The communications interface can be an analog modem, ISDNmodem, cable modem, token ring interface, satellite transmissioninterface (e.g. “direct PC”), or other interfaces for coupling acomputer system to other computer systems.

The processor 748 may be, for example, a conventional microprocessorsuch as an Intel Pentium microprocessor or Motorola power PCmicroprocessor. The memory 752 is coupled to the processor 748 by a bus760. The memory 752 can be dynamic random access memory (DRAM) and canalso include static ram (SRAM). The bus 760 couples the processor 748 tothe memory 752, also to the non-volatile storage 756, to the displaycontroller 754, and to the I/O controller 758.

The I/O devices 744 can include a keyboard, disk drives, printers, ascanner, and other input and output devices, including a mouse or otherpointing device. The display controller 754 may control in theconventional manner a display on the display device 746, which can be,for example, a cathode ray tube (CRT) or liquid crystal display (LCD).The display controller 754 and the I/O controller 758 can be implementedwith conventional well known technology.

The non-volatile storage 756 is often a magnetic hard disk, an opticaldisk, or another form of storage for large amounts of data. Some of thisdata is often written, by a direct memory access process, into memory752 during execution of software in the computer 742. One of skill inthe art will immediately recognize that the terms “machine-readablemedium” or “computerreadable medium” includes any type of storage devicethat is accessible by the processor 748 and also encompasses a carrierwave that encodes a data signal.

Objects, methods, inline caches, cache states and other object-orientedcomponents may be stored in the non-volatile storage 756, or writteninto memory 752 during execution of, for example, an object-orientedsoftware program. In this way, the components illustrated in, forexample, FIGS. 1-6 can be instantiated on the computer system 740.

The computer system 740 is one example of many possible computer systemswhich have different architectures. For example, personal computersbased on an Intel microprocessor often have multiple buses, one of whichcan be an I/O bus for the peripherals and one that directly connects theprocessor 748 and the memory 752 (often referred to as a memory bus).The buses are connected together through bridge components that performany necessary translation due to differing bus protocols.

Network computers are another type of computer system that can be usedwith the present invention. Network computers do not usually include ahard disk or other mass storage, and the executable programs are loadedfrom a network connection into the memory 752 for execution by theprocessor 748. A Web TV system, which is known in the art, is alsoconsidered to be a computer system according to the present invention,but it may lack some of the features shown in FIG. 8, such as certaininput or output devices. A typical computer system will usually includeat least a processor, memory, and a bus coupling the memory to theprocessor.

In addition, the computer system 740 is controlled by operating systemsoftware which includes a file management system, such as a diskoperating system, which is part of the operating system software. Oneexample of an operating system software with its associated filemanagement system software is the family of operating systems known asWindows® from Microsoft Corporation of Redmond, Wash., and theirassociated file management systems. Another example of operating systemsoftware with its associated file management system software is theLinux operating system and its associated file management system. Thefile management system is typically stored in the non-volatile storage756 and causes the processor 748 to execute the various acts required bythe operating system to input and output data and to store data inmemory, including storing files on the non-volatile storage 756.

FIG. 8 depicts a conceptual drawing of a federated system 800. Theexample of FIG. 8 is intended to illustrate some functionality that canexist in a federated control mechanism. The examples are intended toshow how community fields and attributes can be coordinated in afederated system.

The system 800 includes a federated control mechanism 802, a device 804,a community 806, and a community 808. The device 804 includes attributes810, 812, 814, 816. The device 804 is intended to be associated with acontent owner who owns the attributes 810, 812, 814, 816. The communityincludes field 818, 820 and a dynamic update engine 822. As used in thispaper, an engine includes a processor and memory including memorymodules that can be executed by the processor. Attributes and fields aresimilar, but a different name is given for illustrative purposes. Thecommunity 808 includes a field 824. The term “community” is used todescribe the communities 806, 808, but the communities could representany party, including companies, devices of other users, etc. The system800 also includes an optional transaction engine 826.

In the example of FIG. 8, the attribute 810 includes contents that are arequired field for a member of the community 806. Examples of requiredfields could include a username, password, account number, etc. Thefederated control mechanism 802 knows of the association between thefields and can facilitate the matching of the attribute contents to thefield. This can be accomplished by, for example, providing a list ofcommunities to a user of the device 804 and enabling the user toindicate that the user is or wishes to become a member of the community.When the user indicates interest in the community 806, the federatedcontrol mechanism 802 can prompt the user to give the community 806permission to the attribute 810. Even if a field is required, it is notnecessarily the case that the federated control mechanism 802 needensure that the attribute is provided. For example, a user could stilllogin to a community website by keying in a username. The federatedcontrol mechanism 802 can also be implemented at a website associatedwith the community 806, prompting the user for the field 818 and/orasking for permission to the attribute 810. It is more likely that thefederated control mechanism 802 will know about popular websites thanunpopular ones, and be programmed to understand the various fields.However, learning about communities can be automated by crawling forfield values, rather than “learning” by being specifically programmedfor given communities.

In the example of FIG. 8, the field 818 of the community 806 and thefield 824 of the community 808 are equivalent. The federated controlmechanism 802 may or may not automatically share the attribute withsister communities (or automatically share if the user indicates suchsharing is permitted), or it may simply know that the attribute 810 isapplicable to both field 818 and 824 even if the fields are identifieddifferently. Attributes can also be combined into a single field in somecases, such as if birthday is stored as day, month, and year in threedistinct attributes, but is stored as a single string of characters in afield.

In the example of FIG. 8, the federated control mechanism 802 knows thatthe attribute 812 is an optional field 820 in the community 806. In manyrespects, optional fields are treated the same as required fields,though a user may indicate in a risk profile that permissions toattributes associated with optional fields are for “public” attributes,while permissions to attributes associated with required fields include“private” (though perhaps not “secret” or “very private”) attributes.The user is under no obligation to provide permissions to the attribute812, and is unlikely to be inconvenienced by refusing, since the field820 is optional.

In the example of FIG. 8, the federated control mechanism 802 mayprovide the shared attribute 814 to the community 806. In this example,the attribute 814 changes over time. For example, the attribute 814could be associated with a current location or a current rank in aloyalty program. If the attribute 814 is shared with the community 806,a dynamic update engine 822 associated with the community 806 cancompare the attribute 814 with relevant parameters. For example, if auser is indicated to be in a certain city and the community 806 isassociated with a coffee shop, the community 806 may be interested inupdating the user regarding where in the city they can find thecommunity 806 coffee shops. To accomplish this update, the dynamicupdate engine sends a content blob to the device 804, which can bestored as an attribute 816. Note that the attribute may become anattribute of the user, or instead the attribute could be considered tobe owned by the community 806, which like all users of the federatedsystem 800, can have attributes to which permissions are granted. Sinceattributes are intended to have broad meaning, the distinction isacademic. Individual users could also update one another based uponchanging attributes, either their own (which would be a straight-forwardupdate of an old attribute) or of the target's attributes (which wouldessentially be an invitation or advertisement).

With the various transactions that pass through the federated controlmechanism 802, as well as the knowledge base of the federated controlmechanism 802 about users (including communities), the federated system800 can perform additional useful functionality, if it is configured todo so. For example, the federated system 800 could record whatclient/device receives a file; how, where, and when a file is accessedby whom; storage limitations of clients; file transfer size; filetransfer metrics (e.g., latency, throughput, between interchange andclients/devices); what users are accessing, storing, updating, andsharing files; who has permission to file access; user statisticsrelated to file access; and if a client/device is accessing the server.It may also be desirable to know what a user is accessing when and fromwhat device/client; how often a user shares and requests files. Thus,the federated system server can control and track file access based onits sharing paradigm. It may also be desirable to monitor or measurefile requests via, e.g., filesystem services. Some of this functionalityand/or other useful functionality can be provided by what is representedin the example of FIG. 8 as the transaction engine 826.

Some portions of the detailed description may be presented in terms ofalgorithms and symbolic representations of operations on data bitswithin a computer memory. These algorithmic descriptions andrepresentations are the means used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. An algorithm is here, and generally,conceived to be a self-consistent sequence of operations leading to adesired result. The operations are those requiring physicalmanipulations of physical quantities. Usually, though not necessarily,these quantities take the form of electrical or magnetic signals capableof being stored, transferred, combined, compared, and otherwisemanipulated. It has proven convenient at times, principally for reasonsof common usage, to refer to these signals as bits, values, elements,symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that these and similar terms are tobe associated with the appropriate physical quantities and are merelyconvenient labels applied to these quantities. Unless specificallystated otherwise as apparent from the following discussion, it isappreciated that throughout the description, discussions utilizing termssuch as “processing” or “computing” or “calculating” or “determining” or“displaying” or the like, refer to the action and processes of acomputer system, or similar electronic computing device, thatmanipulates and transforms data represented as physical (electronic)quantities within the computer system's registers and memories intoother data similarly represented as physical quantities within thecomputer system memories or registers or other such information storage,transmission or display devices.

The techniques described in this paper relate to apparatus forperforming relevant operations. This apparatus may be speciallyconstructed for the required purposes, or, advantageously, it maycomprise a general purpose computer specially purposed by a computerprogram stored in the computer. Such a computer program may be stored ina computer readable storage medium, such as, but is not limited to, anytype of disk including floppy disks, optical disks, CD-ROMs, andmagnetic-optical disks, read-only memories (ROMs), random accessmemories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any typeof media suitable for storing electronic instructions, and each coupledto a computer system bus.

The algorithms and displays presented herein are not inherently relatedto any particular computer or other apparatus. Various general purposesystems may be used with programs in accordance with the teachingsherein, or it may prove convenient to construct more specializedapparatus to perform the methods of some embodiments. The requiredstructure for a variety of these systems will appear from thedescription below. In addition, the present invention is not describedwith reference to any particular programming language, and variousembodiments may thus be implemented using a variety of programminglanguages.

While techniques have been described by way of example in terms ofcertain embodiments, it will be appreciated by those skilled in the artthat certain modifications, permutations and equivalents thereof arewithin the inventive scope of the present invention. An exhaustive listof all combinations and permutations of embodiments has not beenattempted here but one skilled in the relevant arts will recognizealternative embodiments based on those methods described herein.

1. A method comprising: maintaining one or more attributes of a firstuser; maintaining a risk profile scheme configured by the first user,the risk profile scheme comprising a passive permission table indicatingwhether a second user has permission to the one or more attributes;allowing the first user to grant dynamic permissions to the second userto access the one or more attributes in accordance with the risk profilescheme; allowing the first user to perform content blobulation of theone or more attributes; allowing the first user to perform contentreblobulation of the one or more attributes in accordance with the riskprofile scheme.
 2. The method of claim 1, wherein the second user isassociated with a community.
 3. The method of claim 2, wherein thecommunity comprises: an email community, a shopping community, a socialnetworking community, a corporation, a communications carrier, a groupof professionals, or a group of networked individuals.
 4. The method ofclaim 2, wherein the first user and the community are coupled using afederated exchange.
 5. The method of claim 4, wherein the federatedexchange is configured to exchange content blob updates between thefirst user and the second user, thereby building trust between the firstuser and the second user.
 6. The method of claim 2, wherein the firstuser is associated with the community.
 7. The method of claim 6, whereinthe one or more attributes are owned by the community.
 8. The method ofclaim 2, wherein the first user is associated with another communitydistinct from the community.
 9. The method of claim 2, wherein allowingthe first user to perform the content reblobulation comprises assistingthe first user in finding a business associated with the community. 10.The method of claim 2, wherein allowing the first user to perform thecontent reblobulation comprises assisting the first user use a loyaltyprogram associated with the community.
 11. The method of claim 2,wherein allowing the first user to perform the content reblobulationcomprises assisting the first user manage an account associated with thecommunity.
 12. The method of claim 1, wherein the risk profile scheme isconfigured to condition the content blobulation on occurrence of anevent indicating a likelihood of data loss on a device associated withthe first user.
 13. The method of claim 1, wherein the risk profilescheme is configured to condition the content blobulation on a locationof the first user, or association of the first user in a loyaltyprogram.
 14. The method of claim 1, wherein the content reblobulation isenabled by the content blobulation.
 15. The method of claim 1, whereinthe risk profile scheme is configured to determine whether the seconduser implicitly volunteers to assist with the content reblobulation. 16.The method of claim 1, wherein the one or more attributes comprises arequired attribute of a datastore associated with the first user. 17.The method of claim 1, wherein performing content reblobulationcomprises: maintaining a set of dynamic permission receipts, and sendingcontent to the first user upon a request based on the set of dynamicpermission receipts.
 18. The method of claim 1, the first user is amobile device user.
 19. A system comprising: a first user engineassociated with a first user; a second user engine associated with asecond user; a dynamic permissions engine coupled to the first userengine and the second user engine; a content blob engine coupled to thefirst user engine and the second user engine; a passive permissionsengine coupled to the first user engine and the second user engine; acontent datastore coupled to the passive permissions table; wherein, inoperation: the passive permissions engine maintains one or moreattributes of the first user, and maintains a risk profile schemeconfigured by the first user, the risk profile scheme comprising apassive permission table indicating whether the second user haspermission to the one or more attributes; the dynamic permissions engineallows the first user to grant dynamic permissions to the second user toaccess the one or more attributes in accordance with the risk profilescheme; the content blob engine is configured to perform contentblobulation of the one or more attributes, and to allow the first userto perform content reblobulation of the one or more attributes inaccordance with the risk profile scheme.
 20. A system comprising: meansfor maintaining one or more attributes of a first user; means formaintaining a risk profile scheme configured by the first user, the riskprofile scheme comprising a passive permission table indicating whethera second user has permission to the one or more attributes; means forallowing the first user to grant dynamic permissions to the second userto access the one or more attributes in accordance with the risk profilescheme, thereby performing content blobulation of the one or moreattributes; means for allowing the first user to perform contentreblobulation of the one or more attributes in accordance with the riskprofile scheme.